Languages and frameworks for specifying test artifacts

syntax A con guration is a labeled graph, where vertices represent system nodes andedges represent di erent kinds of connection between nodes. Each node has a symbolic identi er.For example, Figure 4.6 shows three nodes having identi ers x, y and z. This means that any scenarioreferring to C3 must involve lifelines for nodes x, y and z. In order to allow for a richer represen-tation of con gurations, nodes can have two additional attributes of integral types (i.e., integers orenumeration types). The corresponding vertex labels in the graph can take di erent forms:• A constant value from the integral type. For example, in Figure 4.6, the two attributes of nodey have constant values 1 and 2.• A variable name, denoting a value from the type. For example, the rst attribute of nodes xand z must be identical, but their precise value is let unspeci ed (variable v1 ). This value isintended to remain stable in the con guration. Moreover, if a scenario involves several graphcon gurations containing label variable v1 , it must be substituted for a single value. Thus, v1can be seen as a symbolic global constant for the scenario.• A wildcard indicating a don’t care value, e.g., the second attribute of node x. Don’t care valuesdo not need to remain stable in the given con guration.Edges can be labeled by constant values or wildcards. In Figure 4.6, it is assumed that the connec-tion type is an enumerated type safeDistance, communicationDistanceOnly, like in the GMP testingcase study. Nodes x and y have a safeDistance connection, nodes y and z are disconnected, and we donot care about the connection of nodes x and z, they may exhibit unstable connections/disconnectionsduring the con guration. 84CHAPTER 4. A TEST LANGUAGE AND FRAMEWORK FOR MOBILE SYSTEMS Concrete syntax To be as compatible with the original UML speci cation as possible, a spatial con-guration is depicted using object diagrams. A package with the name of the con guration containsall elements. Nodes are represented as instances, slots named l2 and l3 contain the additional labelsde ned for the given node. Labels for edges are represented as stereotypes, because they characterizethe given connection between the two nodes. 4.3.2.2 Spatial elements in the event viewThe event view of a scenario uses UML 2.0 Sequence Diagrams, with some extensions to explicitlyaccount for the spatial con gurations de ned in the spatial view. Abstract syntax An Interaction can be tagged with the termosScenario stereotype (Figure 4.7) toshow that it is a requirement scenario in TERMOS. The termosScenario stereotype has an associationnamed initialCon guration giving the initial con guration of the Interaction.syntax An Interaction can be tagged with the termosScenario stereotype (Figure 4.7) toshow that it is a requirement scenario in TERMOS. The termosScenario stereotype has an associationnamed initialCon guration giving the initial con guration of the Interaction. <>termosScenario<>BasicInteractions::Interaction <>Kernel::Package1* initialConfiguration Figure 4.7: The termosScenario stereotype Con guration changes are represented by global events of the form CHANGE(newConfigName)that induce a global synchronization for all lifelines. Con guration changes cannot be nested into op-erators, except into a consider operator that is at the main level. Con guration changes are “decided”by the environment. Con guration changes arise deterministically and involve all lifelines at the sametime. In this way, the diagram can be decomposed into fragments, where each fragment takes placein a well-de ned spatial con guration. This makes it explicit which communication event occurs inwhich con guration. Predicates (guards of alt operands, state invariants) may refer to variables oftheir current or past con gurations (i.e., node label variables). Concrete syntax Representing the initial con guration with a stereotype’s tagged value ts wellinto the UML framework, the only drawback is that because Interactions are the abstract conceptsrepresenting scenarios, they visually do not appear on a Sequence Diagram. In most of the modelingtools, assigning a stereotype to an Interaction is only re ected in the textual properties view, but noton the diagram itself. For this reason, in the examples used in this chapter the initial con gurations ofthe diagrams are depicted in a comment box containing the text INITIALCONFIG. These commentsare not part of the semantic model, rather they ease the readability of the examples.For the graphical element of a con guration change the symbol of Continuation was reused. Theoriginal Continuation element is not allowed in TERMOS, thus it could not cause a misunderstanding.The con guration changes may involve the dynamic creation, shutdown and restart of nodes. Forexample, a scenario may have three successive con gurations C4 , C5 , C6 (see Figure 4.8(a)), where:• C4 contains a node with identi er x; 4.3. THE TERMOS LANGUAGE85 • C5 does not contain a node with identi er x, but contains a node with identi er y that was notpresent in C4;• C6 contains both nodes x and y.There is no convenient way to illustrate such a dynamic structure in sequence diagrams. Forexample, a lifeline can be stopped, but then it is not possible to restart it. Also, dynamic creation canonly occur as the result of an action performed by an existing lifeline. To solve this problem, we takethe convention that the spatial con guration determines which node is alive/dead at some point ofthe scenario. There is a lifeline for every nodes mentioned in any one of the con gurations. Well-formedness rules If a node is not active at some point of the scenario, then it is not supposedto participate to any communication interaction. Figure 4.8(b) shows an example for such invalidmessages. Checks can be provided to warn the scenario speci er whenever communication is notcompatible with the spatial view:• dead nodes sending and receiving messages;• active nodes exchanging messages while there is no path connecting them in the current con-guration.